Company codes (detailed information)

Company codes (detailed information)

Company codes are necessary to be able to plan on time, for example, for external warehouses, independent of local stock levels. All logistical and planning movements and quantities by company code are recorded separately in sub-monitors. It is thus possible to view all processes per company code.

A company code can be linked to any business object, such as a warehouse or a cost centre. Company codes are usually used with warehouses that are to be managed via separate company codes. The company code can then be used to specify, for example, whether or not its stock quantities or requirements should also be managed in the overall account for the part (common or separate parts planning - requirements stock lists).

In the CyberEnterprise business OS, each document can only be valid for one company code (the assignment to a company code is made via the slot areaAccount). If no company code is specified, the document is only posted to the global monitors. If, for example, a company code is assigned to a warehouse where the "no planning" indicator is set, the transaction data is not posted on the global monitors but exclusively on the company code monitors.

If a follow-on document is created for a document with a company code, the company code is also transferred directly to the follow-on document. The entire planning process is thus contained in one company code.

If company codes have been set up, for example, the MRP account of a part can be displayed for all company codes or for a specific company code. The same applies to the stock/requirements list.

Technical implementation

A company code is represented by class CX_ACCOUNTING_AREA (and its own account class CX_AREA_ACCOUNT), which can be linked to any business object via clearingObjects. Company codes are structured using class CX_ACCOUNTING_AREA_CHART.

Beispiel: CX_STOCK::clearingObjects -> CX_ACCOUNTING_AREA::monitors -> CX_AREA_ACCOUNT

The CX_AREA_ACCOUNT then has two CX_LOG_CUBE as sub-monitors for each part that is posted via it. The sub-monitor, which points with the other dimension to the CX_STOCK_ACCOUNT of the part, displays the minimum and maximum stocks of the part for this company code. The posted stocks are also recorded here, which makes it possible to provide separate stock information for the company code. However, there does not have to be a direct link to the warehouse, as the company code can also be linked to another object.

The second CX_LOG_CUBE subMonitor points with the other dimension to the CX_DISPO_ACCOUNT of the part and thus forms a subset of the posted requirements and requirement coverage, only for this company code.

In the logistics account of a part, the min/max stocks, the staging type and the logistics indicator can be managed separately for each company code. This is realised by the internal wrapping of the connection via DimensionByCondition("type(this)=CX_STOCK_ACCOUNT") on the CX_LOG_CUBE. If the connection is not yet wrapped when such a CX_LOG_CUBE is saved, this is done the first time it is saved. Also the connection from the Logcube to the Dispokonto is wrapped.

The indicator whether to post to the global accounts is not stored in the warehouse, but is determined by the company code.

On the lowest node of the hierarchically arranged company codes, there is an indicator that is binary coded and controls how far above it the documents are also registered. 0 = not at all. 1 = only in the linked company code. 3 = in the linked company code and the higher-level company code...

booking:

With CX_STOCK_ACCOUNT submonitors, the documents are ALWAYS posted to the transactions collection of CX_STOCK_ACCOUNT, even if no general ledger posting is set for the company code. In this case, however, only the total.quantity is counted up, not the current.quantity

In the case of CX_DISPO_ACCOUNT submonitors, the document for a company code without a general ledger posting is NOT included in the transactions collection, but only posted to the subaccounts.